Transporting QoS mapping information in a packet radio network 

Background of the invention 

[0001] This application is a Continuation of International Application 
PCT/FI00/00003 filed on 4 January 2000 which designated the U.S. and was 
5 published under PCT Article 21(2) in English. 

[0002] The invention relates to methods and equipment for control- 
ling Quality of Service (QoS) in mobile communications systems having a 
packet data transmission capability. More specifically, the invention relates to 
sending data packets on the basis of QoS mapping information and transport- 

10 ing QoS mapping information between various nodes in such a mobile com- 
munications system. 

[0003] For the GPRS (General Packet Radio Service) phase 2 and 
UMTS (Universal Mobile Telecommunications System) systems a more com- 
prehensive QoS support is required. For this purpose, QoS-related information 

15 must be maintained at the network boundary elements, e.g., at a Mobile Sta- 
tion (MS) and a GGSN (Gateway GPRS Support Node). 

[0004] Currently it is not possible to transform information needed 
to perform QoS mapping and translation functions between the external net- 
work QoS mechanisms and mobile network specific QoS mechanisms. This 

20 means that only very static QoS translation can be carried out by the mobile 
network boundary nodes. For providing different QoS values for different ap- 
plications (such as real-time or non-real-time multimedia, file transmission, 
background e-mail transfer etc.) means for maintaining consistent information 
at the mobile station and the GGSN nodes are needed. 

25 [0005] No solutions for this problem are known for GPRS/UMTS 

networks. For the Internet, there are mechanisms available that can be used 
to transport QoS or flow specific information. However, this information is in- 
terpreted by every node along the end-to-end transmission path and not only 
by the endpoints (the MS and the GGSN). 

30 Disclosure of the invention 

[0006] An object of the invention is to provide a mechanism for 
enabling more dynamic QoS provisioning for individual applications. This ob- 
ject is achieved with a method and equipment which are characterized by what 
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is disclosed in the attached independent claims. Preferred embodiments of the 
invention are disclosed in the attached dependent claims. 

[0007] The invention is based on a vision that QoS mapping infor- 
mation must be transferred between the GPRS/UMTS network boundaries. In 
5 other words, the invention provides a mechanism for mapping multiple 
downlink (mobile-station-terminated) IP flows (IPflowl, ... IPflown) with differ- 
ent QoS needs to GPRS (or UMTS...) flows. The latter flows are defined by 
PDP (Packet Data Protocol) contexts (PDP1 ... PDPm) or QoS profiles 
(QoSpl ... QoSm) within one profile fulfilling the needs. The basic idea of the 

10 invention is that for at least some data flows (such as real-time applications), 
the mapping being performed in the boundary node (i.e., the GGSN) is based 
on a filter which is configurable (by selection or modification) from a 
user/terminal. Such a filter can be implemented as a set of predetermined pa- 
rameters and/or conditions which are used to identify packets or data flows. A 

15 filter for a mobile station should comprise at least the IP address of the mobile 
station in question. The mobile station's IP address is known from the PDP 
context record, and it does not have to be transmitted in the filter specification 
between the MS and the GGSN. (In rare cases a mobile station may have 
more than one IP address.) Additionally, the filter may comprise any data 

20 which can be used for identifying data packets requiring a certain QoS, and 
which should therefore be multiplexed onto certain PDP contexts, such as a 
Source Address, an RSVP Flow Identifier, a Port Number (e.g. the TCP or 
UDP port number used), an Upper layer protocol (e.g. UDP, RTP, etc.), a Type 
of Service (IPv4), a Connection Type (IPv6) and/or a Traffic Class field (IPv6). 

25 The filter may also comprise the IP Address Space for giving a higher QoS to 
packets coming from a corporate network (e.g. an intranet) than for packets 
from the common Internet. 

[0008] The filter according to the invention is used to define the 
characteristics of the IP flows that are to be mapped to the GPRS or UMTS 

30 flow in question. The terminal may control the filter identifying the filter pa- 
rameters in an information element which can be included for example in a 
PDP context activation or a PDP context modification message. The filter can 
be also be defined/redefined in connection with QoS profile activation or modi- 
fication. 
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[0009] According to a preferred embodiment of the invention, a de- 
fault QoS class is defined. Data flows which do not conform to any defined fil- 
ters are mapped to this default QoS class. 

[0010] The problem solved by the invention is relevant in GPRS 
5 phase 2 and its future evolution, such as UMTS. 

[0011] According to one embodiment, QoS information for the pro- 
file/context is included in the QoS Profile information element as in GPRS 
phase 1. The mapping and filtering information may be transferred in the 'pro- 
tocol configuration options' information element, vendor-specific options, or in 
10 a new information element introduced and devoted to this purpose. This in- 
formation may include source and/or destination IP addresses, TCP and UDP 
port numbers used, upper layer protocol information, possibly Secure Parame- 
ters Index (if IPSEC is used), differentiated services parameters, and RSVP 
filters and flow specifications, or some other identifier or parameters in the 
15 packets. 

[0012] A different quality of service (QoS) profile may be requested 
for each PDP Address. For example, some PDP addresses may be associ- 
ated with E-mail that can tolerate lengthy response times. Other applications, 
such as interactive applications, cannot tolerate delay, and they demand a 

20 very high level of throughput. These different requirements are reflected in the 
QoS profile. If a QoS requirement is beyond the capabilities of a PLMN (Public 
Land based Mobile Network), the PLMN negotiates the QoS profile as close 
as possible to the requested QoS profile. The MS either accepts the negoti- 
ated QoS profile or deactivates the PDP context. 

25 [0013] An advantage of the invention is that the network elements 

(such as the SGSN nodes and the Base Station Subsystem) of a packet radio 
network do not have to interpret all QoS mechanisms of the external networks 
(IP, X.25 etc.) Instead, the mapping can be configured at the mobile-station 
end, and this configuration is transported to the other boundary node (i.e. the 

30 GGSN) of the packet radio network. Thus, the entire packet radio network 
does not have to be updated to support all new QoS mechanisms. 

[0014] The mechanism according to the invention is very generic. In 
other words, it is applicable to a wide variety of situations and configurations. It 
allows flexible access, configuration and use of the filter information in the 

35 GGSN database. Use of the filter according to the invention is entirely case 
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and operator specific. The MS subscriber is provided with means for indicating 
to the gateway node at the mobile/fixed network boundary how the different 
applications, connections, flows, or other attributes should be treated and 
which QoS should be used within the GPRS/UMTS network to transport the 
5 associated packets. Preferably, the GGSN should also maintain applica- 
tion/QoS/flow specific information. 

[0015] Yet another advantage is that the flow/QoS specification 
transferred according to the invention (i.e. in the QoS profile establishment 
procedure or in the PDP context activation or a dedicated message) is very 

10 flexible. It may include source and destination IP addresses, TCP and UDP 
port numbers used, upper layer protocol information, possibly a Secure Pa- 
rameters Index in the case IPSEC is used, differentiated services parameters, 
and RSVP filters and flow specifications, all of which are used to identify ex- 
ternal applications, usages and flows that should be mapped to particular in- 

15 ternal QoS classes or contexts. An advantage of the flexibility is that a new 
application does not necessarily require a new flow in the packet radio net- 
work. Instead, the invention allows flexible re-use of existing flows in an effi- 
cient manner. 

[0016] Alternatively, information can be configured in a more static 
20 manner, in which case no dynamic change of attributes is possible. In this 
case the operator configures static conditions and translation of an external 
QoS to an internal QoS, for example, based on the used TCP/UDP port num- 
bers. Yet another option is not to provide any QoS mapping functions and end- 
to-end QoS at all. 

25 Brief description of the drawings 

[0017] The invention will be described in more detail by means of 
preferred embodiments with reference to the appended drawing wherein: 

[0018] Figure 1 shows the architecture of a known GPRS network; 

[0019] Figure 2 shows a known GPRS transmission plane; 
30 [0020] Figure 3 shows the interworking between different network 

elements; 

[0021] Figure 4 shows a GGSN comprising the filter according to 
the invention; 
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[0022] Figure 5 shows the use of the filter according to the inven- 
tion; 

[0023] Figs. 6 and 7 show transporting filter information in a context 
activation or modification procedure, respectively; and 
5 [0024] Figs. 8 and 9 show two different implementations for config- 

uring the filter information in dedicated messages. 
Detailed description of the invention 

[0025] As shown in Figures 1 and 2, the present invention can be 
applied to any mobile communications system having a packet data transmis- 
10 sion capability. 

[0026] The term 'packet data protocol 1 (PDP) or 'PDP context' as 
used herein should be understood to generally refer to any state in a mobile 
station and in at least one network element or functionality, which state pro- 
vides a data packet transmission path or a tunnel with a specific set of pa- 
is rameters through the mobile communications network. The term 'node' as 
used herein should be understood to generally refer to any network element or 
functionality which handles the data packets transferred through the PDP 
channel. 

[0027] The invention can be especially preferably used for providing 

20 a general packet radio service GPRS in the pan-European digital mobile 
communication system GSM or in corresponding mobile communication sys- 
tems, such as DCS1800 (also known as GSM1800) and PCS (Personal 
Communication System). In the following, preferred embodiments of the inven- 
tion will be described by means of a GPRS packet radio network formed by 

25 the GPRS service and the GSM system without limiting the invention to this 
particular packet radio system. 

[0028] The invention is equally applicable to third generation mobile 
networks, such as UMTS. In this case, the GSM radio interface will be re- 
placed with an UMTS radio interface, as shown in Figure 2. 

30 [0029] Figure 3 illustrates the interworking between different net- 

work elements. After these modifications, a parameter-level mapping between 
differentiated services and RSVP in the Internet and in GPRS may be pro- 
vided as follows, for example: 

[0030] Priority information on the Internet is mapped to service 

35 precedence in the GPRS. An indication concerning real-time vs. non-real-time 
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requirements on the Internet is mapped to a delay class and/or reliability in- 
formation in the GPRS: at least two delay types are needed, but it is also pos- 
sible to map traffic types more precisely to several delay classes. 

[0031] Reliability information may be used to indicate the reliability 

5 requirements of each application in the form of one of at least two reliability 
classes. If reliable transmission (retransmissions, checksums and/or TCP) is 
needed, the profile associated with the data packets indicates reliability class 
1. If reliable delivery over the radio interface is needed, but UDP in the GPRS 
backbone is sufficient, the profile associated with the data packets indicates 

10 reliability class 2. Depending on the requirements, the profile associated with 
the data packets may alternatively indicate reliability class 3, 4 or 5. Reliability 
classes 4 and 5 are used for real-time traffic. 

[0032] A further optional feature of the present invention is a map- 
ping of the QoS parameters used in the mobile-communication network to 

15 those used in a user application in the mobile packet data terminal or those 
used in the external communication system, and vice versa. The MS, knowing 
the requirements of the applications, determines the corresponding QoS pro- 
file values, establishes a new PDP context for these packets and indicates to 
the GGSN how to recognize packets belonging to this context. In the following, 

20 two examples of the mapping will be given. 

[0033] Example 1 (given as an example of how the MS can decide 
which GPRS parameter values it chooses for the context). 

[0034] Simple Integrated Media Access (SIMA) is a new simple ap- 
proach presented as an Internet Draft by K. Kilkki, Nokia Research Center, 

25 June 1997. Internet Drafts are working documents of the Internet Engineering 
Task Force (IETF), its areas, and working groups. The SIMA is used as an ex- 
ample of an Internet QoS scheme because it is capable of providing a uniform 
service concept for different needs from file transfer applications using TCP/IP 
protocol with loose delay and packet loss requirements to real-time applica- 

30 tions with very strict quality and availability requirements. According to the 
SIMA concept, each user defines only two issues before the connection setup: 
a nominal bit rate (NBR) and a selection between real-time and non-real-time 
service classes. The NBR may have eight values from 0 to 7. Mapping of pa- 
rameters from the SIMA to the GPRS and vice versa may be as follows, for 

35 example: 
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[0035] Real-time/non-real-time bit: if this bit indicates real-time re- 
quire-ments, it is mapped to GPRS delay class 1, otherwise it is mapped to de- 
lay class 4. However, delay class 3 may be used for non-real-time services in 
case there is a special way to indicate best-effort traffic, e.g. this bit need not 

5 always be present, or a more precise definition is used to differentiate real- 
time, non-real-time, and best-effort traffic. A lower reliability class value may 
be assigned to real-time traffic than to non-real-time traffic in GPRS. Gener- 
ally, reliability classes 1, 2, and 3 are usually used for non-real-time traffic and 
classes 3, 4, and 5 for real-time traffic in GPRS. For non-real-time traffic, the 

10 higher the NBR is, the lower reliability class value suitable for transmission. 



NBR values 


GPRS service precedence value 


6 and 7 


1 


3, 4, and 5 


2 


0, 1, and 2 


3 



[0036] Different names, such as priority or Nominal Bit Rate and 
traffic type, may also be chosen for the parameters. The QoS Profile may in- 
clude all the existing parameters (service precedence, reliability class, delay 
15 class, mean bit rate and peak bit rate). Alternatively, it could only include some 
of the parameters, such as the mean and peak bit rates. The QoS Profile 
could also include a maximum burst size parameters to ease buffer allocation 
procedure. 

[0037] QoS scheduling in GPRS network elements (e.g. in an 
20 SGSN and a GGSN) is based on the delay class. This may require at least two 
buffers: one for real-time packets (this buffer should be much smaller!) and 
another one for non-real-time packets. Real-time traffic should always be sent 
before non-real-time traffic. Service precedence defines the order in which 
packets can be dropped in case of network congestion. 
25 [0038] Example 2 (describes how to choose QoS values and estab- 

lish a special profile to support a given differentiated services code point, for 
providing proper QoS profile values and a differentiated services code point 
value as filter information for configuring the filter). 

[0039] Mapping a Type of Service (ToS) octet in the headers of IP 
30 PDUs (Packet Data Units) to GPRS attributes. The ToS octet in an IP header 
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is not widely used at the moment. Its original purpose was to include traffic 
type information and to specify what kind of service is required from the packet 
delivery. Because the ToS octet is not in common use nowadays, it is possible 
to redefine the bits in that octet for the purposes of the present invention. A 

5 definition of the ToS octet is given in RFC 791. Bits 0 to 2 of ToS give the 
preference, bits 3 to 5 give the ToS required by the packet (e.g. delay, 
throughput, and reliability levels requested), and bits 6 to 7 are reserved for fu- 
ture use. RFC 1349 extends the ToS field by one bit (taken from the "reserved 
for future" bits). Thus, 4 bits can be used to indicate a ToS. 

10 [0040] Mapping between the precedence bits (0 to 2 in ToS) and 

the GPRS service precedence may be as follows: 



bit values (0 to 2) 


service precedence value 


111 and 110 


001 (highest priority) 


101, 100, and 011 


010 (normal priority) 


010, 001, and 000 


01 1 (lowest priority) 



[0041] There are three different ways to perform the mapping be- 
tween the traffic type information (i.e. ToS field in the ToS octet) and the 

15 GPRS delay class: 

[0042] If only bit 3 in the ToS field is used to indicate the delay re- 
quirements in IP header: value 0 of bit 2 is mapped to GPRS delay class 1 or 
2 and value 1 of bit 2 is mapped to GPRS delay class 4 (best effort). 

[0043] If the whole ToS field in ToS is used for indicating delay re- 

20 quirements, i.e. 4 bits (bits 3-6) are available for that purpose, one possible 
mapping could be: bit value 1000 is mapped to GPRS delay class 1 (i.e. to bit 
value 000), bit value 0100 to GPRS delay class 2 (i.e. to value 001), ToS val- 
ues 0010 and 0001 to GPRS delay class 3 (i.e. to value 010), and ToS value 
0000 to GPRS delay class 4 (i.e. to value 01 1). 

25 [0044] Another way of mapping the IP's ToS bits to the GPRS delay 

classes would be: 1 1 x to delay class 1 , 1 0x to delay class 2, 01 x to delay class 
3, and OOx to delay class 4. In this case, x means that there might be one or 
more additional bits used for the ToS, but they do not have any impact on the 
process of selecting the GPRS delay class. If more delay classes are defined 
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for the GPRS later, the mapping could also take those additional bits into ac- 
count. 

[0045] Currently there is also one bit in the IP ToS field specifying 
the desired reliability level. If this bit is still available in the future, e.g. if the first 
5 choice above is chosen, this bit could carry reliability information and could be 
mapped to GPRS reliability class in the following way: a value 0 in bit 5 inside 
the ToS octet is mapped to the reliability class 000 (subscribed reliability class) 
and a value 1 is mapped to the reliability class 001 (defining the most reliable 
service). The use of that bit may however be too vague because the GPRS 
10 defines many other reliability levels as well and this cannot be expressed using 
only one bit. 

[0046] According to a preferred embodiment of the invention, a de- 
fault QoS class is defined, and data flows not conforming to any of the map- 
ping criteria defined by the filter(s) are mapped to the default QoS class. 

15 [0047] The mapping described above in Example 2 may be applied 

in a rather similar way in IPv6. The name of the appropriate field is then Traffic 
Class instead of the ToS. 

[0048] Figure 3 illustrates the operation of a GPRS mobile station 
and GPRS network elements, as well as integration with external network QoS 

20 concepts. The MS or the software in the terminal equipment TE (e.g. in a lap- 
top computer) provides mapping of external network QoS requirements to 
GPRS QoS mechanisms. The TE could, for example, provide QoS manage- 
ment functions through an Application Programming Interface (API). The ap- 
plication-level software may insert QoS information or a profile tag into the 

25 data packets, e.g. inside the IP header itself, or it can indicate the correct flow 
which the packet belongs to using some other suitable means. It can also use 
the RSVP to convey the necessary information via appropriate mapping layers 
to lower layers. The software of the MS may, alternatively, decide the QoS 
profile based e.g. on the used source and destination IP addresses, or on the 

30 source and destination port numbers, or on some other information configured 
to the MS. 

[0049] For Mobile Originated (MO) data, the MS schedules data 
packets based on the QoS information received from the application or from 
the GPRS protocol suite in the Terminal Equipment. The MS schedules the 
35 MO packets according to their delay class. On the SNDC layer, the MS selects 
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the appropriate LLC SAP (Service Access Point) indicated by the SGSN dur- 
ing PDP context activation or modification. 

[0050] Figure 4 illustrates a GGSN comprising the filter according to 
the invention. The GGSN receives MS-terminated data packets from multiple 
5 sources, collectively referred to as Service Providers SP. Figure 4 shows three 
typical service providers: an Internet Service Provider ISP for providing access 
to the Internet; a Company Network Server CNS for providing access to closed 
areas of the Internet, commonly called intranets and extranets; and Content 
Providers CP for providing access to various entertainment and news services, 

10 such as video-on-demand, etc. 

[0051] The GGSN comprises a scheduler/translator ST. As its 
name implies, it schedules transmission of packets on the basis of network 
load, packet priority, arrival time, etc. The scheduling part of the ST is largely 
known to the skilled reader. 

15 [0052] The translating part of the ST makes use of the filter Fl ac- 

cording to the invention. It maps data packets from the IP networks (items 11 
and 12 in Figure 1) to the packet radio network (item 13 in Figure 1). The in- 
vention provides a solution for a situation where several applications and data 
flows share a common IP address but require different QoS values. 

20 [0053] Figure 5 illustrates the use of the filter Fl according to the in- 

vention at the GGSN. In step 5-1 the GGSN receives a data packet addressed 
to a given mobile station MS. The GGSN reads the MS's IP address from the 
corresponding protocol header and uses the filter Fl to determine the corre- 
sponding PDP context or QoS profile. The MS's IMSI can be determined from 

25 the packets' destination IP address. In step 5-2, the GGSN obtains the corre- 
sponding Tunnel Identifier TID. Next, in step 5-3, the GGSN sends the data 
packet via the SGSN to the MS via that particular context which is associated 
with an appropriate QoS for this packet. 

[0054] Figure 6 shows how a mobile station can configure the QoS 

30 mapping and interworking actions by means of a context activation procedure 
according to the invention. In step 6-1, the MS sends to the SGSN an Activate 
PDP Context Request comprising an NSAPI, a PDP type, a PDP address, an 
Access Point Name, QoS Requested, a Filter Specification and PDP configu- 
ration options. (For understanding the present invention, the important pa- 

35 rameters are the Filter and QoS information.) The MS may use the PDP Ad- 
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dress to indicate whether it requires the use of a static or a dynamic PDP ad- 
dress. In the latter case, the MS shall leave the PDP Address empty. The MS 
may use the Access Point Name to select a reference point to a certain exter- 
nal network. The Access Point Name is a logical name referring to the external 
5 packet data network that the subscriber wishes to connect to. The QoS Re- 
quested indicates the desired QoS profile. The Filter specification indicates 
which external data packets are associated with a particular PDP context. 
Packets indicated by the filtering conditions of this filter should be considered 
as belonging to this particular PDP context. PDP Configuration Options may 

10 be used to request optional PDP parameters from the GGSN (see 
GSM recommendation 09.60). PDP Configuration Options are sent transpar- 
ently through the SGSN. 

[0055] Using dynamic configuration and dynamic PDP addresses 
involves the problem of how to ensure that the context activation affects the 

15 correct GGSN, and how the GGSN knows whether to activate a new context 
with the same IP address or a different address. Three solutions for this prob- 
lem can be found: 

[0056] 1. Using an Access Point Name which points to a certain 
GGSN node and indicates that another context is needed, and using the same 

20 IP address. 

[0057] 2. Adding an indication (such as a new information element) 
to the context activation request, indicating to the GGSN (and the SGSN) that 
another context is needed. This context has the same IP address as the previ- 
ous one. In this case the SGSN selects the same GGSN as for the previous 

25 context of that PDP type. 

[0058] 3. Adding the PDP and IP addresses desired for the context 
to the context activation request message. This PDP/IP address may be given 
to one of the previous contexts, i.e. a dynamic address. In this case, the 
SGSN selects the GGSN which is handling that particular address. 

30 [0059] Security functions may be performed in step 6-2, but they 

are not relevant to understanding the invention. 

[0060] In step 6-3, the SGSN validates the request 6-1. The SGSN 
creates a Tunnel Identifier TID for the requested PDP context by combining 
the IMSI stored in the MM context with the NSAPI received from the MS. The 

35 SGSN may restrict the requested QoS attributes considering its capabilities, 
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the current load, and the subscribed QoS profile. Next, in step 6-3 the SGSN 
sends a Create PDP Context Request (comprising a PDP type, a PDP ad- 
dress, an Access Point Name, the negotiated QoS Profiles, the desired filter, 
the TID, and PDP configuration options) to the GGSN. The GGSN may also 
5 restrict the requested QoS attributes considering its capabilities, and the cur- 
rent load. If the MS requests a dynamic address, then the SGSN lets a GGSN 
allocate the dynamic address. The SGSN may restrict the requested QoS at- 
tributes given its capabilities, the current load, and the subscribed QoS profile. 
The SGSN sends a Create PDP Context Request (PDP Type, PDP Address, 

10 Access Point Name, QoS Negotiated, Filter spec, TID, Selection Mode, PDP 
Configuration Options) message to the affected GGSN. The Access Point 
Name is the APN Network Identifier of the APN selected. The PDP Address 
shall be empty if a dynamic address is requested. The GGSN may use the Ac- 
cess Point Name to find an external network. The Selection Mode indicates 

15 whether a subscribed APN was selected, or whether a non-subscribed APN 
sent by MS or a non-subscribed APN chosen by SGSN was selected. The 
GGSN may use the Selection Mode when deciding whether to accept or reject 
the PDP context activation. For example, if an APN requires subscription, then 
the GGSN is configured to accept only the PDP context activation that re- 

20 quests a subscribed APN as indicated by the SGSN with the Selection Mode. 
The GGSN creates a new entry in its PDP context table and generates a 
Charging Id. The new entry allows the GGSN to route PDP PDUs between the 
SGSN and the external PDP network, and to start charging. The GGSN may 
further restrict the QoS Negotiated considering its capabilities and the current 

25 load. The GGSN will maintain information for QoS mapping and multiplex in- 
coming data packets from the external network onto the active PDP contexts 
according to the defined filtering conditions at the GGSN. For outgoing pack- 
ets, a certain external QoS might be associated with the packets of a particular 
PDP context. The GGSN then returns a Create PDP Context Response (TID, 

30 PDP Address, BB Protocol, Reordering Required, PDP Configuration Options, 
QoS Negotiated, Charging Id, Cause) message to the SGSN. The PDP Ad- 
dress is included if the GGSN allocated one. The BB Protocol indicates 
whether TCP or UDP should be used to transport user data on the backbone 
network between the SGSN and the GGSN. The Reordering Required indi- 

35 cates whether the SGSN should reorder N-PDUs before delivering the 
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N-PDUs to the MS. The PDP Configuration Options contain optional PDP pa- 
rameters that the GGSN may transfer to the MS. These optional PDP parame- 
ters may be requested by the MS in the Activate PDP Context Request mes- 
sage, or may be sent unsolicited by the GGSN. The PDP Configuration Op- 
5 tions are sent transparently through the SGSN. The Create PDP Context mes- 
sages are sent over the GPRS backbone network. If the QoS Negotiated re- 
ceived from the SGSN is incompatible with the PDP context being activated 
(e.g., the reliability class is insufficient to support the PDP type), then the 
GGSN rejects the Create PDP Context Request message. The compatible 

10 QoS profiles can be configured by the GGSN operator. 

[0061] In step 6-4, the GGSN returns a Create PDP Context Re- 
sponse (comprising a TID, a PDP Address, the negotiated QoS Profiles, and 
PDP configuration options) to the SGSN. The SGSN inserts the NSAPI with 
the GGSN address in the PDP context. If the MS has requested a dynamic 

15 address, the PDP address received from the GGSN is inserted in the PDP 
context. The SGSN selects a Radio Priority based on QoS Negotiated, and re- 
turns an Activate PDP Context Accept (PDP Type, PDP Address, Tl, QoS Ne- 
gotiated, Radio Priority, PDP Configuration Options) message to the MS. The 
SGSN is now able to route PDP PDUs between the GGSN and the MS, and to 

20 start charging. 

[0062] Next, in step 6-5, the SGSN selects a Radio Priority Level 
based on each negotiated QoS profile, and returns an Activate PDP Context 
Accept (comprising a PDP type, a PDP Address, an NSAPI, the negotiated 
QoS Profiles, a Radio Priority Level and a SAPI for each QoS profile, the filter 

25 and PDP configuration options) to the MS. Now the SGSN is able to route 
PDP PDUs between the GGSN and the MS. The SAPI indicates which QoS 
profile uses which SAPI. 

[0063] Figure 7 shows a context modification procedure. In step 7-1 
the MS sends the SGSN a Modify PDP Context Request. In step 7-3 the 

30 SGSN sends to the GGSN an Update PDP Context Request. Both of these 
requests comprise the filter with modified parameters. The filter indicates 
which external data packets are associated with a particular PDP context. 
Packets indicated by the filtering conditions should be interpreted as belonging 
to this particular PDP context and they should be provided with the QoS nego- 

35 tiated for the context. The Update PDP Context Request message is used to 
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add, modify or cancel a QoS profile of a PDP context. If the GGSN receives 
from the SGSN a negotiated QoS which is incompatible with the PDP context 
being modified (e.g. the reliability class is insufficient to support the PDP type), 
the GGSN rejects the request. Compatible QoS profiles are configured by the 
5 GGSN operator. The GGSN may again restrict the requested QoS attributes 
considering its capabilities, and the current load. The GGSN stores the negoti- 
ated QoS values. The GGSN revises the QoS mapping information to conform 
to the new filter spec and Qos Profile negotiated (included in the request mes- 
sage). In steps 7-4 and 7-5 a positive response is returned to the MS. 

10 [0064] Basic versions of the messages 7-1 through 7-5 are known 

from GPRS phase 2. According to the invention, the messages 7-1 and 7-3 
are modified to convey the desired filtering parameters (and the messages 7-4 
and 7-5 are modified to return a suitable acknowledgement). 

[0065] According to yet another embodiment of the invention, the 

15 filter function in a first direction (e.g. downlink) can be modified using informa- 
tion included in the packets sent in the second direction (e.g. uplink). This em- 
bodiment requires no extra signalling. According to this exemplary embodi- 
ment, the following traffic classes are defined (RT = Real-Time, NRT = Non- 
Real-Time): 

20 



Traffic class 


Conversational (RT) 


Streaming (RT) 


Interactive (NRT) 


Background (NRT) 




• guaranteed capacity 


• guaranteed capac- 


• best effort 


• best effort 




• no ARQ 


ity 


• ARQ 


• ARQ 






• ARQ (MAC level) 


• interactive 


• background 






• Add. Buffering in 


www, Telnet 


downloading of 






application 


• RT control 


e-mail, calen- 








channel 


dar events, etc. 


Delay 


100ms, 200ms, 400ms 


<1s 


2s 


N/A 


BER 


10-3, 10 -4, 10-5 


10- 5 , 10- 6 , 10- 7 , 10- 8 


< 10-9 


<10- 9 


Max bitrate 


Guaranteed 


Guaranteed 


Not guaranteed 


Not guaranteed 


Service 


High, medium, low 


High, medium, low 


High, medium, low 


High, medium, low 


precedence 
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[0066] Conversational and Streaming classes are real-time oriented 
traffic classes for which resources are reserved. Interactive and Background 
classes are best effort classes, which do not have reserved resources. For 
these classes, GPRS style resource allocation can be used, i.e. the MS sends 
5 radio resource requests on demand. 

[0067] For the real time classes, i.e. the Conversational and 
Streaming classes, the method presented above is very efficient, i.e. the filter 
information is carried in PDP context operations to the GGSN so that GGSN 
can map incoming IP packets to the correct QoS class. However, with Interac- 

10 tive and Background classes this involves large amounts of signalling, which in 
some situations might be unacceptable. An example of such a situation is a 
query sent to a Domain Name Server DNS (not shown), in which case the net 
flow might consist of only two packets. 

[0068] In this example, the Interactive class is selected as the de- 

15 fault QoS class. This means that if there is no information about the QoS re- 
quirement of an incoming flow, or the flow information does not conform to any 
of the filter conditions, the Interactive class will be selected. In addition, flows 
belonging to the background class can be identified by the GGSN "on the fly". 
This means that when the GGSN gets a packet from the MS in the Back- 

20 ground class, it will take notice of the flow identification information, and mod- 
ify the filter characteristics associated with the background class, to map the 
downlink flow corresponding to the flow in question to the Background class. 
When a packet comes in the downlink direction, the GGSN checks the flow 
identification information associated with the Background class. If the flow filter 

25 information associated with the Background class matches the header infor- 
mation of the received IP packet, then the packet is directed to the Back- 
ground class. 

[0069] Flow information related to the Background class can be 
handled as follows. The MS has knowledge about flows that should be carried 

30 using the Background class. The user can configure this mapping of flows to 
the Background class. For example, the user can configure file transfers to 
use the Background class by using a suitable configuration application. Alter- 
natively, the information can be obtained e.g. from some external QoS infor- 
mation (e.g. Internet QoS information). In other words, the MS has filter criteria 

35 for flows to be mapped to the Background class. An essential feature of this 
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embodiment is that the MS has knowledge on which flows should be directed 
to the Background class, and it sends these packets to the corresponding link. 
When the GGSN receives packets from the MS, it knows the QoS class the 
packets are associated with. When the GGSN gets a packet from the Back- 
5 ground class it checks whether it already has an entry for that flow in a list (not 
shown) which contains flow information of all flows belonging to the Back- 
ground class. If there is no entry for that flow in the list, the GGSN modifies the 
filter used when mapping the downlink flows to the Background class so that 
the downlink flow corresponding to the uplink flow the received packet belongs 
10 to will be mapped to the Background class. This can be done by including the 
flow identification information of the uplink packet to the flow information list 
from which the downlink packets are mapped to the Background class. So, 
flows belonging to the background class are identified in the GGSN "on the 
fly". 

15 [0070] When the GGSN receives a packet from the Internet or from 

any other external network, it checks the filter information associated with 
Conversational, Streaming and Background classes. If the GGSN finds that 
the characteristics of the packet conform to the relevant filter conditions, it for- 
wards the packet to the corresponding QoS class. If there is no entry for that 

20 particular flow, then the packet is forwarded to the Interactive class, which is 
the default class. 

[0071] This embodiment dramatically decreases the need for 
signalling because the Interactive class will be the most frequently used QoS 
class. There are many cases in which IP packets do not actually form a flow, 

25 but there are instead only one or a few IP packets going uplink and a few 
packets coming downlink as a response. A DNS query is a good example of 
this kind of behaviour. Signalling of the PDP context modification in these 
cases would cause a relatively high amount of signalling which can be avoided 
using this embodiment. Instead, only the initial PDP context activation is 

30 needed to obtain an IP address for the MS. 

[0072] A residual problem in the approach shown in Figures 6 and 7 
is that it may not be clear how to add filtering information in addition to the filter 
for the PDP context, or modify the existing filters without first removing all the 
existing filters and then resending all filter information, including the changes. 
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In other words, if PDP context activation and modification procedures are al- 
ways used, the entire filtering information has to be included in the messages 
even if only one parameter value is to be changed. Adding a new filter requires 
sending all filters at the same time. Consequently, Figures 8 and 9 illustrate a 
5 preferred embodiment of the invention which aims at solving this residual 
problem. 

[0073] It is proposed that there should be at least one dedicated 
message for configuring the filter information. In this context, 'dedicated' 
means that the message does not carry PDP context information. A filter han- 

10 die should be defined for identifying a certain filter of a certain PDP context. 
This filter handle may consist of a Tunnel Identifier TID, which indicates the 
user and the PDP context, and a filter number FN. The latter can be a se- 
quence number selected by the MS when creating a filter. In summary, the fil- 
ters can be configured by the following procedures: 

15 [0074] 1. One or more filters may be created in association with the 

PDP context activation procedure (see Figure 6). In this case, one or many fil- 
ter information elements are included in the PDP context activation messages, 
each filter element being identified by a distinct filter number (1 , 2, 3, etc.). 

[0075] 2. Filters may be modified in association with the PDP con- 

20 text modification procedure (see Figure 7). In this case, one or more filter pa- 
rameters of one or more filters may be modified by adding filter information 
elements in the PDP context modification request. Independent filters are 
identified by a filter number. New filters may be created using this procedure 
as well. In this case a new filter information element (e.g. a new, previously 

25 unused filter number) is included in the modification request message. 

[0076] 3. New filter operations (one or more dedicated messages): 
Three operations between the MS and the GGSN are proposed for configuring 
the filters: 

[0077] 3.1 Create filter: This message carries TID information, as 
30 well as the new filter element and a new filter number. The GGSN creates a 
new filter according to the contents of the message. 

[0078] 3.2 Modify filter: This message carries TID information, as 
well as the new filter element replacing the old one and a filter number identify- 
ing the particular filter to the replaced. The GGSN replaces the filter attrib- 
35 ute(s) of the indicated filter with the new one(s). 
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[0079] 3.3 Delete filter: This message carries TID information, as 
well as the filter number of the filter to be removed. The GGSN removes that 
particular filter. 

[0080] It should be noted that the operations 3.1 through 3.3. may 
5 be combined to use only one or two different message types, but also three 
different messages (one per each operation) may be defined. The defined 
messages may be GTP messages in which case new GTP messages should 
be defined (in other words, new message identifiers in GTP). In this case, the 
TID information is automatically included in the GTP packet headers and it 
10 does not have to be a separate information element in the message. Alterna- 
tively, a new protocol for filter operations may be defined between the MS and 
the GGSN, in which case the SGSN would be totally transparent to these 
messages. 

[0081] Figure 8 shows a first implementation of the new filter opera- 

15 tions 3.1 through 3.3. In step 8-0 a PDP context is activated for the MS. The 
details of this operation have already been outlined in connection with the pre- 
vious figures. In step 8-1 the MS sends a Create Filter message to the 
SGSN. This message has as parameters the Tunnel Identifier TID (which 
specifies the PDP context) and a filter number FN (which specifies a certain 

20 filter within the PDP context). Naturally, the Create Filter message should 
also include the characteristics of the filter. In step 8-2 the message is relayed 
from the SGSN to the GGSN. Steps 8-3 and 8-4 are corresponding acknowl- 
edgements. In step 8-5 data transmission takes place to/from the MS. Steps 8- 
6 through 8-9 correspond to steps 8-1 through 8-4, except that in the latter 

25 steps the MS (or an application being executed) modifies an existing filter by 
sending a Modify Filter message. In steps 8-11 through 8-14 a filter, which is 
no longer needed, is deleted by sending a Delete Filter message. 

[0082] The implementation shown in figure 8 is based on existing 
protocols. The messages between the MS and the SGSN can be e.g. session 

30 management messages and the messages between the SGSN and the GGSN 
can be e.g. GTP messages. As can be seen, negotiating a filter between an 
MS and a GGSN is needlessly complex because there are no predefined pro- 
tocols between the MS and the GGSN. 

[0083] For clarity, the messages 8-1, 8-6 and 8-11 have been 

35 shown as three separate messages. Alternatively, all these operations could 
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use only one message, e.g. Configure Filter, which includes a parameter 
such as 1=create, 2=modify, 3=delete. 

[0084] Figure 9 shows an alternative implementation where there is 
a protocol layer between the MS and the GGSN, and the SGSN is a transpar- 
5 ent node which does not interpret the messages in any way. 

[0085] The embodiment and the different implementations shown in 
figures 8 and 9 provide a very flexible scheme where independent (e.g. appli- 
cation-specific) filters can be added and modified dynamically using special fil- 
ter operations. A special filter handle is used to identify the independent filters. 

10 [0086] The description only illustrates preferred embodiments of the 

invention. The invention is not, however, limited to these examples but it may 
vary within the scope of the appended claims. For example, it is not necessary 
that the receiving terminal is a mobile station but it can be any network ele- 
ment. Similarly, it is not necessary that the MT data packets originate from the 

15 IP network. Instead, the invention is applicable e.g. in a MS to MS call via a 
GGSN node. In this case the leg from one MS to the GGSN is a first commu- 
nication subsystem and the leg from the GGSN to the other MS is a second 
communication subsystem. 



